





I HAVE BEEN INVOLVED WITH PROJECT MANAGEMENT 
FOR FIFTY YEARS. RATHER THAN FOCUSING ON ONE 
PARTICULAR STORY, I’D LIKE TO TELL YOU THE LARGER 
STORY OF MY CAREER. THOUGH MANY OFTHE PROJECTS 
TOOK PLACE OVER THIRTY YEARS AGO, THEIR LESSONS 
ARE STILL RELEVANT TODAY. 

I BECAME A PROJECT MANAGER AT AGE TWENTY-TWO AT 

Eglin Air Force Base. I managed the droning of the B47 
to fly unmanned, and 1 had zero experience to take on 
that task. What 1 learned is the real way you acquire risk 
aversion: I was scared to death that I'd fail. 

This developed a characteristic that 1 carried with 
me throughout my career. The strongest thing a project 
leader can feel, in terms of risk, is the risk of failing. 
So I took it upon myself to learn everything about the 
airplane and the guidance control system by searching 
out the best in the aerospace community. At that time, 
Lockheed was doing a modification of the aircraft. 
Boeing designed and built the aircraft, and Sperry was 
doing the guidance control system. I made sure that I 
spent hours and hours with each of them to understand 
exactly what 1 was responsible for. 

SETTING THE PATTERN 

The pattern that I established for my career was one of 
research and faith in the skills of other team members. 
Through the years as I worked on other projects, 
the philosophy I developed is that you can be very 
successful if you spend the time to organize yourself, 
find qualified people, and understand the objectives. 
Once you decide what you need to do, you can organize 
people around it. You can get the skills. That’s the 
strongest way you can become risk averse — to be 
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dependent on the strengths of others and bring them 
into the program as best you can. 

When we worked on Viking, the first landing 
mission to Mars, it was done at Langley Research 
Center, which is really a technology center. Langley 
was selected because of its strong technology base, and 
the Jet Propulsion Laboratory (JPL) was busy with the 
Mariner and Voyager projects. 

We ended up using this to our advantage. Not only 
did we concentrate on finding qualified people, but 
we found that by doing the project at a technological 
center, we were able to get people who were strong in 
the technical skills it took to do the re-entry, to solve 
aerodynamic problems, and to develop the parachute. 
So Langley turned out to be a technological advantage. 

THE EARLY BIRD OPENS THE CHUTE 

But the parachute reminds me of the different ways 
in which the first and second Mars Missions dealt 
with risk. They were both successful, but the roads 
getting there were different. In 1969 we did a full- 
landed simulated test at White Sands. We simulated 
the spacecraft in the necessary ways and developed the 
parachute very early. The reason we did that was to 
make sure that the parachute got sized properly, since 
the whole integration of the spacecraft was going to be 
built around the size of it. 

The recent Rover Missions on Mars waited too 
long to do that test. They did it about nine months 
before they were supposed to launch and the parachute 
didn’t fully deploy. So they had to go back and do a 
redesign of the parachute, but the whole spacecraft 
was designed and fixed. At that point there were many 
variables to look at and problems to solve, and the risks 
went up tremendously because of the limitations they 
had in changing the design. 


So not only should you organize yourself and get 
qualified people, but you have to do things early. You've 
got to build enough reserve in your thinking so that you 
can minimize problems. The other thing is: If you have 
a threat of cancellation over your head, or your project 
might be moved to another center, or parts of it are 
being deleted — you allow for that, and you adjust. If you 
stop working because you’re worried about changes to 
your program, you start adding risks to it. 

THE GROUP EFFORT 

Also, you have to be disciplined in carrying out 
verv critical analysis. Don't move on without it. On 
Viking, we brought the science community in early 
for the 1975 launch. They attended every design 
review and participated very strongly. We wanted their 
fingerprint on everything that was done from an 
engineering viewpoint. 

My mentor Jim Martin insisted that if this was 
going to be their opportunity for a scientific achieve- 
ment, then they needed to participate in the program 
all along the way. Would you believe that 72 scientists 
moved to JPL from their various universities for one 
year during the Viking Mission just because he said 
that was where the action was? He said, "If you want to 
play on my program, that's the way it's going to be.” You 
can’t avoid risk over the telephone. 

PLANNING FOR 

THE WORST-CASE SCENARIOS 

During Viking, we also developed about 500 scenarios 
of all the things that could possibly go wrong 
during the development and flight. We adopted a 
very pessimistic view and used these scenarios to 
establish various plans for cost offsets, budget shifts, 
and solutions to technical problems. 
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We did have a problem that I'm not proud of, but it 
also taught me something about risk. We had money 
problems, and we were told that we weren’t getting any 
more money. The cost was fixed, and the schedule was 
also fixed since it was a planetary launch. 

Well, we had a risk problem related to a test. One of 
the problems with the fixed budget was that we weren't 
going to be able to perform the terminal-landing 
test. This was a very sophisticated full-systems test 
where we would drop the spacecraft through a Mars 
landing simulation. We had pitched the cost problem 
to headquarters, saying we needed $1.2 million dollars, 
and we were denied the money. So we were going to 
have to launch without the critical terminal-landing 
test — a very high-risk decision. 

Jim Martin accepted it at the time. He said, “Ok, 
as long as you hold my hand. I’ll jump into the pool 
with you." So we made the decision to go ahead with 
it. We ended up being successful, but there was a large 
amount of risk attached. If we had failed we would 
have lost $1 billion dollars (and this was in 1970) 
because we couldn’t secure the $1.2 million for the 
necessary preliminary test. That just doesn’t make 
sense. It wasn’t a schedule problem; it -was strictly a 
cost problem. 

GIVE IT TO THEM STRAIGHT 

This is where I really learned a big lesson. As a 
project leader, you've got to take the problem before 
management and tell them the risks that they are taking 
by withholding funds. You've got to be tough and hang 
in there. At this point, we were seven years into the 
project. Jim decided to swallow hard, pray a lot, and 
cross his fingers that the test worked. We had a happv 
ending, but under other circumstances, it could have 
been a disaster. 

This is an example where management made the 
decision to take the risk against the security. I think 
that's the thing that has to change. We're in a high-risk 
business, and we have to approach it in a conservative 
way. But the Agency needs to realize that sometimes the 
failures make you learn and progress. 

I'm not saying that you set out expecting to fail, 
but there is such a thing as so much risk-aversion 
that you don't do anything. You’ve got to maintain a 
healthy amount of it and move ahead. And these are 
just some of the strategies I learned over mv fifty years 
that have helped me to do that. • 



Lessons 

• Sometimes pessimism can help to reduce risk. 
Planning for possible problems — and developing a cost 
and schedule-efficient way of dealing with them — can 
provide an important project “safety net." 

• A small amount of funding is never worth the failure 
of a large-scale project. Project managers have to fight to 
get the resources they need to do things right — not cross 
their fingers and hope for the best. 


Question 

In a situation where mistakes and misjudgments can cost 
millions of dollars, how do you strike the right balance between 
healthy risk-aversion and playing it too safe? 


ANGELO “GUS” GUASTAFERRO has had a lengthy career 
in Program and Project Management, 
both at NASA and with private industry. 
j| His previous story, “Bringing Up Baby,” 
* was printed in ASK 17. 
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